1. Technical Field
The invention relates generally to real-time operating systems, and more specifically, to real-time operating systems that need to respond to external events within a limited interval from system boot.
2. Related Art
As systems become more complex, boot time requirements for real time operating systems (RTOS) used in embedded systems continue to increase. For example, the vehicles, such as automobiles, trucks, farming equipment, mining equipment, golf carts, mobile robots and the like, may employ telematics systems, such as GPS navigational systems, wireless communications, automatic driving assistance systems, and the like, which provide a wide variety of useful features. These telematics systems may be driven by a Controller Area Network (CAN) and Media Oriented Systems Transport (MOST®) buses that can transmit messages within a very short time period after the system is powered-on. The telematics systems often need the ability to receive, and possibly respond to, these messages, often within a very short amount of time. These timing requirements may be less than the time required by the RTOS to fully boot and begin running standard device drivers.
For example, a CAN bus master device can send a “Power Up” message to all devices on the bus around 65 ms after the system is powered-on, and the telematics systems must respond to this message within 100 ms. After this initial power-on handshaking sequence, the telematics system may need to buffer (and possibly reply to) additional messages received over the CAN bus at a rate around one message every 10 ms. When coupled with the fact that the first CPU instruction may not executed until 10 ms after power-on, telematics systems must be able to respond to these messages in approximately 55 ms. These demanding boot time requirements make it unlikely that the RTOS will be fully operational before the first “Power Up” CAN message. This may be due to bottlenecks in the booting process such as copying the OS image into RAM. Typical OS boot times from power-on-reset (POR) to starting the first user application may be measured in 100's of milliseconds.
To meet these timing requirements, auxiliary communications processors have been used to supplement the functionality of the RTOSs. For example, when CAN messages are delivered, the auxiliary processor can receive the message and capture any required data. These tasks then can be passed over to a device driver once the OS has loaded. While these auxiliary processors have been incorporated into the embedded systems to meet timing requirements, they can be expensive in a price sensitive market. Moreover, hardware solutions can be difficult and expensive to modify should the need arise. Therefore a need exists for a low-cost, easily modifiable solution for meeting startup timing requirements that is operational and provides limited functionality before the operating system is running.